不确定性|传统_Redis的持久化策略（RDBAOFRDBAOF混合持久化）

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Redis的持久化策略（RDBAOFRDB-AOF混合持久化）相关的知识，希望对你有一定的参考价值。

文章目录

• Redis的持久化策略
• • 持久化概念
  • 持久化策略
  • • RDB&＃xff1a;
    • AOF&＃xff1a;
    • • AOF持久化的文件同步机制&＃xff1a;
      
      
    • RDB-AOF混合持久化&＃xff1a;
    
    
  
  

持久化概念

由于 redis 是一个内存数据库&＃xff0c;所谓内存数据库&＃xff0c;就是将数据库中的内容保存在内存中&＃xff0c;这与传统的mysql&＃xff0c;Oracle等关系型数据库直接将内容保存到硬盘中相比&＃xff0c;内存数据库的读写效率比传统数据库要快的多&＃xff08;内存的读写效率远远大于硬盘的读写效率&＃xff09;。但是保存在内存中也随之带来了一个缺点&＃xff0c;一旦断电或者宕机&＃xff0c;那么内存数据库中的数据将会全部丢失。

redis持久化是指在指定的时间间隔内将内存中的数据集快照(snapshotting)写入磁盘&＃xff0c;恢复时是将快照文件读入内存&＃xff0c;用来保证数据的持久性

持久化策略

Redis支持RDB持久化、AOF持久化、RDB-AOF混合持久化这三种持久化方式。

RDB&＃xff1a;

RDB(Redis Database)是Redis默认采用的持久化方式&＃xff0c;它以快照的形式将进程数据持久化到硬盘中。

RDB会创建一个经过压缩的二进制文件&＃xff0c;文件以“.rdb”结尾&＃xff0c;内部存储了各个数据库的键值对数据等信息。

RDB持久化的触发方式有两种&＃xff1a;

• 手动触发&＃xff1a;通过SAVE或BGSAVE命令触发RDB持久化操作&＃xff0c;创建“.rdb”文件&＃xff1b;
• 自动触发&＃xff1a;通过配置选项&＃xff0c;让服务器在满足指定条件时自动执行BGSAVE命令。

例如手动触发&＃xff1a;

就会生成一个rdb文件&＃xff1a;

其中&＃xff0c;SAVE命令执行期间&＃xff0c;Redis服务器将阻塞&＃xff0c;直到“.rdb”文件创建完毕为止。而BGSAVE命令是异步版本的SAVE命令&＃xff0c;它会使用Redis服务器进程的子进程&＃xff0c;创建“.rdb”文件。BGSAVE命令在创建子进程时会存在短暂的阻塞&＃xff0c;之后服务器便可以继续处理其他客户端的请求。

总结&＃xff1a;BGSAVE命令是针对SAVE阻塞问题做的优化&＃xff0c;Redis内部所有涉及RDB的操作都采用BGSAVE的方式&＃xff0c;而SAVE命令已经废弃&＃xff01;

BGSAVE命令的执行流程&＃xff0c;如下图&＃xff1a;

BGSAVE命令的原理&＃xff0c;如下图&＃xff1a;

RDB持久化的优缺点如下&＃xff1a;

• 优点&＃xff1a;RDB生成紧凑压缩的二进制文件&＃xff0c;体积小&＃xff0c;使用该文件恢复数据的速度非常快&＃xff1b;
• 缺点&＃xff1a;BGSAVE每次运行都要执行fork操作创建子进程&＃xff0c;属于重量级操作&＃xff0c;不宜频繁执行&＃xff0c;所以RDB持久化没办法做到实时的持久化。

AOF&＃xff1a;

AOF&＃xff08;Append Only File&＃xff09;&＃xff0c;解决了数据持久化的实时性&＃xff0c;是目前Redis持久化的主流方式。

AOF以独立日志的方式&＃xff0c;记录了每次写入命令&＃xff0c;重启时再重新执行AOF文件中的命令来恢复数据。

AOF的工作流程包括&＃xff1a;命令写入&＃xff08;append&＃xff09;、文件同步&＃xff08;sync&＃xff09;、文件重写&＃xff08;rewrite&＃xff09;、重启加载&＃xff08;load&＃xff09;&＃xff0c;如下图&＃xff1a;

AOF默认不开启&＃xff0c;需要修改配置项来启用它&＃xff1a;

修改配置文件内容&＃xff0c;重启服务器&＃xff1a;

appendonly yes # 启用AOF
appendfilename "appendonly.aof" # 设置文件名


AOF以文本协议格式写入命令&＃xff0c;如下面写入命令&＃xff1a;

*3\\r\\n$3\\r\\nset\\r\\n$5\\r\\nhello\\r\\n$5\\r\\nworld\\r\\n


文本协议格式具有如下的优点&＃xff1a;

1. 文本协议具有很好的兼容性&＃xff1b;
2. 直接采用文本协议格式&＃xff0c;可以避免二次处理的开销&＃xff1b;
3. 文本协议具有可读性&＃xff0c;方便直接修改和处理。

AOF持久化的文件同步机制&＃xff1a;

为了提高程序的写入性能&＃xff0c;现代操作系统会把针对硬盘的多次写操作优化为一次写操作。

1. 当程序调用write对文件写入时&＃xff0c;系统不会直接把数据写入硬盘&＃xff0c;而是先将数据写入内存的缓冲区中&＃xff1b;
2. 当达到特定的时间周期或缓冲区写满时&＃xff0c;系统才会执行flush操作&＃xff0c;将缓冲区中的数据冲洗至硬盘中&＃xff1b;

这种优化机制虽然提高了性能&＃xff0c;但也给程序的写入操作带来了不确定性。

1. 对于AOF这样的持久化功能来说&＃xff0c;冲洗机制将直接影响AOF持久化的安全性&＃xff1b;
2. 为了消除上述机制的不确定性&＃xff0c;Redis向用户提供了appendfsync选项&＃xff0c;来控制系统冲洗AOF的频率&＃xff1b;
3. Linux的glibc提供了fsync函数&＃xff0c;可以将指定文件强制从缓冲区刷到硬盘&＃xff0c;上述选项正是基于此函数。

appendfsync选项的取值和含义如下&＃xff1a;

AOF持久化的优缺点如下&＃xff1a;

• 优点&＃xff1a;与RDB持久化可能丢失大量的数据相比&＃xff0c;AOF持久化的安全性要高很多。通过使用everysec选项&＃xff0c;用户可以将数据丢失的时间窗口限制在1秒之内。
• 缺点&＃xff1a;AOF文件存储的是协议文本&＃xff0c;它的体积要比二进制格式的”.rdb”文件大很多。AOF需要通过执行AOF文件中的命令来恢复数据库&＃xff0c;其恢复速度比RDB慢很多。AOF在进行重写时也需要创建子进程&＃xff0c;在数据库体积较大时将占用大量资源&＃xff0c;会导致服务器的短暂阻塞。

RDB-AOF混合持久化&＃xff1a;

Redis从4.0开始引入RDB-AOF混合持久化模式&＃xff0c;这种模式是基于AOF持久化构建而来的。用户可以通过配置文件中的“aof-use-rdb-preamble yes”配置项开启AOF混合持久化。

Redis服务器在执行AOF重写操作时&＃xff0c;会按照如下原则处理数据&＃xff1a;

• 像执行BGSAVE命令一样&＃xff0c;根据数据库当前的状态生成相应的RDB数据&＃xff0c;并将其写入AOF文件中&＃xff1b;
• 对于重写之后执行的Redis命令&＃xff0c;则以协议文本的方式追加到AOF文件的末尾&＃xff0c;即RDB数据之后。

通过使用RDB-AOF混合持久化&＃xff0c;用户可以同时获得RDB持久化和AOF持久化的优点&＃xff0c;服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作&＃xff0c;又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。